Optimizing and Enhancing Performance for Parity Based Storage

ABSTRACT

A mechanism is provided for optimizing and enhancing performance for parity based storage, particularly redundant array of independent disk (RAID) storage. The mechanism optimizes a repetitive pattern write command for performance for storage configurations that require parity calculations. The mechanism eliminates the need for laborious parity calculations that are resource intensive and add to IO latency. For repetitive write commands that span across the full stripe of a RAID5 or similar volume, the mechanism calculates parity by looking at the pattern and the number of columns in the volume. The mechanism may avoid the XOR operation altogether for repetitive pattern write commands. The mechanism may enhance secure delete operations that use repetitive pattern write commands by eliminating data reliability operations like parity generation and writing altogether.

BACKGROUND

The present application relates generally to an improved data processingapparatus and method and more specifically to mechanisms for optimizingand enhancing performance for parity based storage, particularlyredundant array of independent disk (RAID) storage.

Redundant Array of Independent Disks (RAID), is a technology thatprovides increased storage functions and reliability through redundancy.This is achieved by combining multiple disk drive components into alogical unit, where data is distributed across the drives in one ofseveral ways called “RAID levels.” RAID is an example of storagevirtualization. RAID is now used as an umbrella term for computer datastorage schemes that can divide and replicate data among multiplephysical disk drives. The physical disks are said to be in a RAID array,which is accessed by the operating system as one single disk. Thedifferent schemes or architectures are named by the word RAID followedby a number (e.g., RAID 0, RAID 1). Each scheme provides a differentbalance between two key goals: increase data reliability and increaseinput/output performance.

A number of standard schemes have evolved which are referred to aslevels. There were five RAID levels originally conceived, but many morevariations have evolved, notably several nested levels and manynon-standard levels (mostly proprietary).

RAID 0 (block-level striping without parity or mirroring has no (orzero) redundancy. RAID 0 provides improved performance and additionalstorage but no fault tolerance. Simple stripe sets are normally referredto as RAID 0. Any disk failure destroys the array, and the likelihood offailure increases with more disks in the array. A single disk failuredestroys the entire array because when data is written to a RAID 0volume, the data is broken into fragments called blocks. The number ofblocks is dictated by the stripe size, which is a configurationparameter of the array. The blocks are written to their respective diskssimultaneously on the same sector. This allows smaller sections of theentire chunk of data to be read off the drive in parallel, increasingbandwidth. RAID 0 does not implement error checking, so any error isuncorrectable. More disks in the array means higher bandwidth, butgreater risk of data loss.

In RAID 1 (mirroring without parity or striping), data is writtenidentically to multiple disks (a “mirrored set”). The array continues tooperate as long as at least one drive is functioning. With appropriateoperating system support, there can be increased read performance, andonly a minimal write performance reduction; implementing RAID 1 with aseparate controller for each disk in order to perform simultaneous reads(and writes) is sometimes called multiplexing (or duplexing when thereare only 2 disks).

In RAID 2 (bit-level striping with dedicated Hamming-code parity), alldisk spindle rotation is synchronized, and data is striped such thateach sequential bit is on a different disk. Hamming-code parity iscalculated across corresponding bits on disks and stored on at least oneparity disk.

in RAID 3 (byte-level striping with dedicated parity), all disk spindlerotation is synchronized, and data is striped so each sequential byte ison a different disk. Parity is calculated across corresponding bytes ondisks and stored on a dedicated parity disk.

RAID 4 (block-level striping with dedicated parity) is identical to RAID5 (see below), but confines all parity data to a single disk, which cancreate a performance bottleneck. In this setup, files can be distributedbetween multiple disks. Each disk operates independently which allowsI/O requests to be performed in parallel, though data transfer speedscan suffer due to the type of parity. The error detection is achievedthrough dedicated parity and is stored in a separate, single disk unit.

RAID 5 (block-level striping with distributed parity) distributes parityalong with the data and requires all drives but one to be present tooperate; the array is not destroyed by a single drive failure. Upondrive failure, any subsequent reads can be calculated from thedistributed parity such that the drive failure is masked from the enduser. However, a single drive failure results in reduced performance ofthe entire array until the failed drive has been replaced and theassociated data rebuilt.

RAID 6 (block-level striping with double distributed parity) providesfault tolerance of two drive failures. The array continues to operatewith up to two failed drives. This makes larger RAID groups morepractical, especially for high-availability systems. This becomesincreasingly important as large-capacity drives lengthen the time neededto recover from the failure of a single drive. Single-parity RAID levelsare as vulnerable to data loss as a RAID 0 array until the failed driveis replaced and its data rebuilt. The larger the drive, the longer therebuild takes. Double parity gives time to rebuild the array without thedata being at risk if a single additional drive fails before the rebuildis complete.

Many RAID levels employ an error protection scheme called “parity.” TheXOR parity calculation is a widely used method in information technologyto provide fault tolerance in a given set of data. In Boolean logic,there is an operation called exclusive or (XOR), meaning “one or theother, but not neither and not both.” The XOR operator is central to howparity data is created and used within an array. It is used both for theprotection of data, as well as for the recovery of missing data. Thus, aRAID controller must perform the XOR command every time a stripe iswritten to create parity.

SUMMARY

In one illustrative embodiment, a method, in a data processing system,is provided for optimizing and enhancing performance for parity basedstorage. The method comprises receiving a repetitive write command andan associated pattern to be written to a portion of parity based storagevolume. The method further comprises optimizing parity calculation forthe repetitive write command. The method further comprises writing thepattern to the portion of the parity based storage volume based on theoptimization.

In other illustrative embodiments, a computer program product comprisinga computer useable or readable medium having a computer readable programis provided. The computer readable program, when executed on a computingdevice, causes the computing device to perform various ones of, andcombinations of, the operations outlined above with regard to the methodillustrative embodiment.

In yet another illustrative embodiment, a system/apparatus is provided.The system/apparatus may comprise one or more processors and a memorycoupled to the one or more processors. The memory may compriseinstructions which, when executed by the one or more processors, causethe one or more processors to perform various ones of, and combinationsof the operations outlined above with regard to the method illustrativeembodiment.

These and other features and advantages of the present invention will bedescribed in, or will become apparent to those of ordinary skill in theart in view of, the following detailed description of the exampleembodiments of the present invention.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The invention, as well as a preferred mode of use and further objectivesand advantages thereof, will best be understood by reference to thefollowing detailed description of illustrative embodiments when read inconjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram illustrating a data processing system in whichaspects of the illustrative embodiments may be implemented;

FIG. 2 is a flowchart illustrating operation of a mechanism foroptimizing repetitive write operations in accordance with anillustrative embodiment;

FIG. 3 is a flowchart illustrating operation of a mechanism forperforming a secure delete operation in accordance with an illustrativeembodiment;

FIG. 4 is a flowchart illustrating operation of a mechanism foroptimizing a repetitive write for a secure delete operation inaccordance with an illustrative embodiment;

FIG. 5 depicts a cloud computing node according to an illustrativeembodiment;

FIG. 6 depicts a cloud computing environment according an illustrativeembodiment; and

FIG. 7 depicts abstraction model layers according to an illustrativeembodiment.

DETAILED DESCRIPTION

The illustrative embodiments provide a mechanism for optimizing andenhancing performance for parity based storage, particularly redundantarray of independent disk (RAID) storage. The mechanism optimizes arepetitive pattern write command for performance for storageconfigurations that require parity calculations.

In one illustrative embodiment, the mechanism makes use of the fact thatthe certain commands, such as the WRITE-SAME, command, involve writingrepetitive patterns. The mechanism eliminates the need for laboriousparity calculations. For WRITE-SAME commands that span across the fullstripe of a RAID5 or similar volume, the mechanism calculates parity bylooking at the pattern and the number of columns in the volume. Themechanism may avoid the XOR operation altogether for repetitive patternwrite commands.

In another illustrative embodiment, the mechanism enhances secure deleteoperations that use repetitive pattern write commands by eliminatingdata reliability operations like parity generation and writingaltogether. Because secure delete operations require no reliability, themechanism can eliminate parity generation. This has the potential toboost performance of the secure delete operation significantly as therewilt be no I/O and no processor computation involved for paritygeneration.

The WRITE-SAME command is a small computer system interface (SCSI)command that is used to overwrite large sections of disk with repetitivepatterns, such as zeroes. Using WRITE-SAME has the benefit that the hostdoes not have to unnecessarily transfer repetitive patterns in order toachieve overwriting of a region on the disk. Because large sections ofthe disk are involved during an overwrite operation, optimizing thiscommand can benefit applications that use the command.

FIG. 1 is a block diagram illustrating a data processing system in whichaspects of the illustrative embodiments may be implemented. Application110 receives a file access 102, such as a request from a user. In theillustrative embodiment, the file access may be a request to overwrite alarge portion of a storage volume or a request to perform a securedelete operation, for example. In response to the file access 102,application 110 makes one or more calls to operating system and/or filesystem 120.

Operating system/file system 120 sends a WRITE-SAME SCSI command tostorage controller 130 with a pattern to be repeatedly written to thevolume. RAID controller 140 then writes the pattern to disk0 151, disk1152, disk2 153, and disk3 154. More particularly, in the depictedexample, RAID controller 140 uses RAID5 level to perform block-levelstriping with distributed parity. While the depicted example shows RAID5with four columns using a WRITE-SAME SCSI command, the illustrativeembodiments may apply to other parity based storage configurations andother repetitive write commands.

The significance and use of the WRITE-SAME SCSI command is on the rise,as the command is used for server virtualization, thin provisioning, andcloud storage applications to achieve multi-tenancy. Thus, it isimportant to improve the performance of the command. In accordance withthe illustrative embodiment, RAID controller 140 takes advantage of therepetitive nature of the WRITE-SAME command to make the command operatefaster. RAID controller 140 uses a formula involving the number ofcolumns in the RAID5 volume, full stripe size, and the data patternissued by the application in order to calculate parity for theWRITE-SAME command, instead of using XOR operation to arrive at parity.

As an example, suppose a pattern ABC of size 512 bytes is issued via theWRITE-SAME command to a RAID5 volume with 4 columns of stripe width 12k, i.e., three data blocks of size 4 k and one parity block of size 4 k.In order to calculate the parity, RAID controller 140 considers thefollowing:

1) The size of data to be written using the WRITE-SAME command must spanthe full stripe size of the RAID5 volume.

2) For even number of RAID5 columns (true in the example described aboveand the example shown in FIG. 1), the RAID controller 140 sets theparity to be the same as the pattern, because the XOR of an odd numberof equal patterns is the pattern itself. With an even number of columns,one column is the parity; therefore, the RAID controller 140 wouldperform the XOR operation over an odd number of data blocks.

3) For an odd number of RAID5 columns, parity is set to zero, becausethe XOR of a pattern an even number of times results in a value of zero.Again, excluding the parity block, the number of data blocks is an evennumber. The XOR of an even number of equal patterns is zero.

4) The stripe unit width must be a whole number multiple of the size ofthe data pattern sent via the WRITE-SAME command.

The above formula my be easily extended to cover other parity basedvirtual devices, such as RAID4, RAID6, etc.

It is also possible to use repetitive write commands to perform a securedelete operation. A secure delete operation is an act of securelypurging contents of storage such that there are no remains on thestorage. Secure delete is one of the vital aspects of data security overstorage. Many regulatory compliances mandate the need for the securedelete operation. Secure purging of data to meet secure deleterequirements is a very common approach. Because secure delete involvesmultiple levels of writing with different formats, depending on thespecification being implemented, it proves to be costly to systemperformance, because the system must perform many I/O operations.

In accordance with an illustrative embodiment, secure delete canleverage the WRITE-SAME command for repetitive writes to ensure minimumdata remanence and to ensure that the application host is not tied upperforming this operation for tong durations of time.

As stated above, file access 102 may request a secure delete operationto be performed. In accordance with another illustrative embodiment,operating system/file system 120 may perform the secure delete operationusing one or more WRITE-SAME commands. Operating system/file system 120may set a special flag of the WRITE-SAME command, or any other commandexecuting repetitive write cycles at storage controller or diskcontroller level, indicating that the command is part of a secure deleteoperation. In one example embodiment, the flag my be part of the cachedescriptor block (CDB) of the command.

When the secure delete flag is set for a WRITE-SAME command, RAIDcontroller may skip the parity generation operation altogether andsimply overwrite the data blocks of a stripe leaving the parity blockthe same. RAID controller 140 may implement the above by skipping paritygeneration cycles. The feature may be optional and user configurable sothat no associated standards are broken and backward compatibilityissues, if any, are maintained.

Considering the example described above, a file of size 1 GB on a RAID5configuration with 1 KB block size, which is being securely deleted witha modest three overwrite cycles. The mechanism of the illustrativeembodiment saves 3,145,728 parity generation and write cycles.

Application 110 has an associated configuration file 112. A user mayconfigure application 110 to flag repetitive write commands as beingpart of a secure delete operation setting a secure delete enable/disablefield in configuration file 112. In another example embodiment, a usermay configure application 110 to flag a repetitive write command toindicate that the pattern is of the appropriate size for optimization atRAID controller 140. Thus, the user may enable/disable optimization bysetting an optimization enable/disable field in configuration file 112.

Similarly, storage controller 130 has an associated configuration file132. A user may set a secure delete enable/disable field inconfiguration file 132 to enable or disable setting the secure deleteflag at the storage controller level. In another example embodiment, theuser may configure storage controller 130 to enable or disable allparity calculation optimization by setting an optimizationenable/disable field in configuration file 132.

RAID controller 140 has an associated configuration file 142. Usingconfiguration file 142, a user may configure the RAID controller 140 toenable/disable parity computation optimization or to enable/disableparity computation altogether when the repetitive write command isflagged as being part of a secure delete operation.

As will be appreciated by one skilled in the art, the present inventionmay be embodied as a system, method, or computer program product.Accordingly, aspects of the present invention may take the form of anentirely hardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,aspects of the present invention may take the form of a computer programproduct embodied in any one or more computer readable medium(s) havingcomputer usable program code embodied thereon,

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CDROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, in abaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Computer code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,optical fiber cable, radio frequency (RF), etc., or any suitablecombination thereof.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java™, Smalltalk™, C++, or the like, and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer, or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to the illustrativeembodiments of the invention. It will be understood that each block ofthe flowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmariner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions thatimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus, or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

FIG. 2 is a flowchart illustrating operation of a mechanism foroptimizing repetitive write operations in accordance with anillustrative embodiment. Operation begins, and the mechanism receives apattern to be written to a storage volume by a repetitive write command(block 202). The storage volume may be a block-level storage scheme withparity, such as RAID5. The mechanism determines whether the storagevolume has an even or odd number of columns (block 204). If the volumehas an even number of columns, the mechanism sets the parity equal tothe pattern (block 206). If the volume has an odd number of columns, themechanism sets the parity equal to zero (block 208). Thereafter, themechanism writes the stripes to the disks (block 210), and operationends.

FIG. 3 is a flowchart illustrating operation of a mechanism forperforming a secure delete operation in accordance with an illustrativeembodiment. Operation begins, and the mechanism determines a pattern towrite to disks to purge the data stored in the volume (block 302). Themechanism determines whether to use a repetitive write command, such asthe WRITE-SAME command, for the current level of the secure deleteoperation (block 304). The mechanism may determine whether to use arepetitive write command based on fields set by a user in aconfiguration file.

If the mechanism determines to use a repetitive write command, themechanism determines whether to flag the command as being part of asecure delete operation (block 306). The mechanism may determine whetherto set the flag based on fields set by a user in a configuration file.If the mechanism determines to meta flag, the mechanism sends therepetitive write command to the controller with the flag (block 308). Ifthe mechanism determines not to set the flag in block 306, the mechanismsends the command to the controller without the flag set (block 310),meaning the RAID controller will calculate parity according to theoperations depicted in the flowchart in FIG. 2.

Thereafter, the mechanism determines whether the pattern is the lastpattern (block 312), meaning the mechanism determines whether thecurrent level of the secure delete command is the last level. If themechanism determines that the pattern is not the last pattern, thenoperation returns to block 302 to determine the next pattern to write tothe disks. If the mechanism determines that the pattern is the lastpattern in block 312, then operation ends. Returning to block 304, ifthe mechanism determines that a repetitive write command is not to beused, the mechanism performs a normal write to disk (block 314) andoperation ends.

FIG. 4 is a flowchart illustrating operation of a mechanism foroptimizing a repetitive write for a secure delete operation inaccordance with an illustrative embodiment. Operation begins, and themechanism receives a repetitive write command and a pattern to bewritten to the storage volume (block 402). The mechanism determineswhether the secure delete flag is set in the command (block 404). If thesecure delete flag is set, the mechanism writes the stripes to the diskswithout parity (block 406). The mechanism may simply leave the parityblocks without overwriting. Thereafter, operation ends.

If the secure delete flag is not set in block 404, the mechanismdetermines parity (block 408) and writes the stripes to disks withparity (block 410). The mechanism may determine parity according to theoperations depicted in the flowchart in FIG. 2. Thereafter, operationends.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The aspects of the illustrative embodiments may apply to cloud computingservices and data protection. The aspects of the illustrativeembodiments may be expanded to file systems and distributed file systemsover clusters. When an application issues a file deletion command, tocomply with compliance rules, the operating system, file system, orstorage controller may translate the command to a secure delete and passa list of blocks to be deleted. The controller may avoid RAID paritycalculations for all blocks involved, along with just one logical blockoptimization described above. The aspects of the illustrativeembodiments may extend the advantages described to large blocks,directly proportional to the file size,

In a clustered file system, such as the General Parallel File System(GPFS), where data is distributed across various logical units (LUNs)attached to multiple RAID controllers, each RAID controller cancalculate the parity only once, as described above, for repetitive writecommands and avoid calculation of parity for all LUNs on a node, thusimproving performance significantly and resulting in secure deletecompleting quickly, saving computing resources, memory, and networktraffic. The illustrative embodiments minimize network traffic as thefile system now sends the list of blocks and pattern only once, insteadof sending data for every block.

It is understood in advance that although this disclosure includes adetailed description on cloud computing, implementation of the teachingsrecited herein are not limited to a cloud computing environment. Rather,embodiments of the present invention are capable of being implemented inconjunction with any other type of computing environment now known orlater developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based email). Theconsumer does not manage or control the underlying cloud infrastructureincluding network, servers, operating systems, storage, or evenindividual application capabilities, with the possible exception oflimited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting for loadbalancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure comprising anetwork of interconnected nodes.

Referring now to FIG. 5, a schematic of an example of a cloud computingnode is shown. Cloud computing node 510 is only one example of asuitable cloud computing node and is not intended to suggest anylimitation as to the scope of use or functionality of embodiments of theinvention described herein. Regardless, cloud computing node 510 iscapable of being implemented and/or performing any of the functionalityset forth hereinabove.

In cloud computing node 510 there is a computer system/server 512, whichis operational with numerous other general purpose or special purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that may besuitable for use with computer system/server 512 include, but are notlimited to, personal computer systems, server computer systems, thinclients, thick clients, handheld or laptop devices, multiprocessorsystems, microprocessor-based systems, set top boxes, programmableconsumer electronics, network PCs, minicomputer systems, mainframecomputer systems, and distributed cloud computing environments thatinclude any of the above systems or devices, and the like.

Computer system/server 512 may be described in the general context ofcomputer system executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 512 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 5, computer system/server 512 in cloud computing node510 is shown in the form of a general-purpose computing device. Thecomponents of computer system/server 512 may include, but are notlimited to, one or more processors or processing units 516, a systemmemory 528, and a bus 518 that couples various system componentsincluding system memory 528 to processor 516.

Bus 518 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, and notlimitation, such architectures include Industry Standard Architecture(ISM bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus,Video Electronics Standards Association (VESA) local bus, and.Peripheral Component Interconnects (PGI) bus.

Computer system/server 512 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 512, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 528 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 530 and/or cachememory 532. Computer system/server 512 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 534 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 518 by one or more datamedia interfaces. As wilt be further depicted and described below,memory 528 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 540, having a set (at least one) of program modules 542,may be stored in memory 528 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. Program modules 542 generally carry out the functionsand/or methodologies of embodiments of the invention as describedherein. Computer system/server 512 may also communicate with one or moreexternal devices 514 such as a keyboard, a pointing device, a display524, etc.; one or more devices that enable a user to interact withcomputer system/server 512; and/or any devices (e.g., network card,modem, etc.) that enable computer system/server 512 to communicate withone or more other computing devices. Such communication can occur viaInput/Output (I/O) interfaces 522. Still yet, computer system/server 512can communicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 520. As depicted, network adapter 520communicates with the other components of computer system/server 512 viabus 518. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 512. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

Referring now to FIG. 6, illustrative cloud computing environment 650 isdepicted. As shown, cloud computing environment 650 comprises one ormore cloud computing nodes 610, such as cloud computing node 510 in FIG.5, with which local computing devices used by cloud consumers, such as,for example, personal digital assistant (PDA) or cellular telephone654A, desktop computer 654B, laptop computer 654C, and/or automobilecomputer system 654N may communicate. Nodes 610 may communicate with oneanother. They may be grouped (not shown) physically or virtually, in oneor more networks, such as Private, Community, Public, or Hybrid cloudsas described hereinabove, or a combination thereof. This allows cloudcomputing environment 650 to offer infrastructure, platforms and/orsoftware as services for which a cloud consumer does not need tomaintain resources on a local computing device. It is understood thatthe types of computing devices 654A-N shown in FIG. 6 are intended to beillustrative only and that computing nodes 610 and cloud computingenvironment 650 can communicate with any type of computerized deviceover any type of network and/or network addressable connection (e.g.,using a web browser).

Referring now to FIG. 7, a set of functional abstraction layers providedby cloud computing environment 650 (FIG. 6) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 7 are intended to be illustrative only and embodiments of theinvention are not limited thereto. As depicted, the following layers andcorresponding functions are provided:

Hardware and software layer 760 includes hardware and softwarecomponents. Examples of hardware components include mainframes, in oneexample tBM® zSeries® systems; RISC (Reduced Instruction Set Computer)architecture based servers, in one example IBM pSeries® systems; IBMxSeries® systems; IBM BladeCenter® systems; storage devices; networksand networking components. Examples of software components includenetwork application server software, in one example HIM WebSphere®application server software; and database software, in one example IBMDB2® database software. (IBM, zSeries, pSeries, xSeries, BladeCenter,WebSphere, and DB2 are trademarks of International Business MachinesCorporation registered in many jurisdictions worldwide).

Virtualization layer 762 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers;virtual storage; virtual networks, including virtual private networks;virtual applications and operating systems; and virtual clients.

In one example, management layer 764 may provide the functions describedbelow. Resource provisioning provides dynamic procurement of computingresources and other resources that are utilized to perform tasks withinthe cloud computing environment. Metering and Pricing provide costtracking as resources are utilized within the cloud computingenvironment, and billing or invoicing for consumption of theseresources. In one example, these resources may comprise applicationsoftware licenses, Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal provides access to the cloud computing environment forconsumers and system administrators. Service level management providescloud computing resource allocation and management such that requiredservice levels are met. Service Level Agreement (SLA) planning andfulfillment provide pre-arrangement for, and procurement of, cloudcomputing resources for which a future requirement is anticipated inaccordance with an SLA.

Workloads layer 766 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation; software development and lifecycle management; virtualclassroom education delivery; data analytics processing; and,transaction processing.

Particular aspects of the illustrative embodiments may be implemented inmanagement layer 764, virtualization layer 762, or hardware and softwarelayer 760. For example, a file access overwriting or deleting a portionof storage may originate in management layer 764, in virtual servers orvirtual applications in virtualization layer 762, or in an applicationrunning on mainframes or servers in hardware and software layer 760, forexample. Illustrative embodiments for optimizing repetitive writecommands and secure delete operations may be implemented in storagewithin hardware and software layer 760.

Thus, the illustrative embodiments provide mechanisms for optimizing andenhancing performance for parity based storage, particularly redundantarray of independent disk (RAID) storage. The mechanism optimizes arepetitive pattern write command for performance for storageconfigurations that require parity calculations. The mechanism may makeuse of the fact that the certain commands, such as the WRITE-SAMEcommand, involve writing repetitive patterns. The mechanism eliminatesthe need for laborious parity calculations. For repetitive writecommands that span across the full stripe of a RAID5 or similar volume,the mechanism calculates parity by looking at the pattern and the numberof columns in the volume. The mechanism may avoid the XOR operationaltogether for repetitive pattern write commands. The mechanism mayenhance secure delete operations that use repetitive pattern writecommands by eliminating data reliability operations like paritygeneration and writing altogether. Because secure delete operationsrequire no reliability, the mechanism can eliminate parity generation.This has the potential to boost performance of the secure deleteoperation significantly as there will be no I/O and no processorcomputation involved for parity generation.

Implementation of the illustrative embodiments is very simple andstraight forward. The illustrative embodiments help reduce the timeconsumed to execute repetitive write command significantly. Theillustrative embodiments save resources on the device server executingthe repetitive write command. The illustrative embodiments can makesecure delete operations involving repetitive write commands speed upconsiderably. Given that large sections of the disk can be overwrittenduring secure delete operations, executing repetitive write commandsfaster has benefits for the applications that require secure delete. Inaddition, the illustrative embodiments can ensure that initialize tozero required by server virtuatization solutions can execute faster.Storage Multi Tenancy operations that are very frequent in CloudApplications use cases can benefit by a faster zero out or overwriteoperations.

Furthermore, the illustrative embodiments avoid CPU/IO cycles for RAIDparity generation/writing altogether. Every write cycle avoided resultsin less heat dissipation and generates less carbon footprint byimpacting the running cost of clouds/datacenters. Less heat dissipationresults in lower cooling requirements and, hence, less power forcooling. Write cycles being power consumption intensive, every writecycle saved reduces power consumption.

In addition, fewer write cycles directly lessens the adjacent trackerasure problems associated with hard disk drives. In hard disk drives(HDDs), deleterious effects can occur that are known as adjacent trackerasure (ATE), all caused by inadvertent erasure of data that isunderneath certain portions of the recording head during disk driveroperation. If one keeps writing to a particular track continuously,there is a good probability that data from adjacent tracks can getdeleted. Hence, a, data track is refreshed after the adjacent trackshave been continuously written for a certain number of times in order toreduce the damage. This problem is highly visible when one has data thathas secure delete requirements imposed on it. This is due to repetitivewrites on the same blocks as per many current compliance requirements.By avoiding parity write cycles, the illustrative embodiments tend tosave the refresh cycles, which otherwise the HDD would compensate fordue to the ATE effect.

It must be noted that some disk controllers scan incoming user data forrepetitive zeros written via a standard SCSI WRITE command with repeatedblocks of zeros. Since the disk controller already scans for zeros, thesame technique mentioned in this invention can be extended to includeparity optimization for WRITE zeros as well, without any additionaloverhead due to scanning of zeros in user data (because that is alreadydone).

As noted above, it should be appreciated that the illustrativeembodiments may take the form of an entirely hardware embodiment, anentirely software embodiment or an embodiment containing both hardwareand software elements. In one example embodiment, the mechanisms of theillustrative embodiments are implemented in software or program code,which includes but is not limited to firmware, resident software,microcode, etc.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc) can be coupled to the system eitherdirectly or through intervening I/O controllers. Network adapters mayalso be coupled to the system to enable the data processing system tobecome coupled to other data processing systems or remote printers orstorage devices through intervening private or public networks. Modems,cable modems and Ethernet cards are just a few of the currentlyavailable types of network adapters.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention, the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A method, in a data processing system, for optimizing and enhancingperformance for parity based storage, the method comprising: receiving arepetitive write command and an associated pattern to be written to aportion of a parity based storage volume; optimizing parity calculationfor the repetitive write command; and writing the pattern to the portionof the parity based storage volume based on the optimization.
 2. Themethod of claim 1, wherein the parity based storage volume employsblock-level striping with parity and wherein optimizing paritycalculation comprises: determining a parity based on the pattern and anumber of columns in the parity based storage volume.
 3. The method ofclaim 2, wherein determining the parity comprises: responsive to thenumber of columns in the parity based storage being even, setting theparity equal to the pattern; and responsive to the number of columns inthe parity based storage being odd, setting the parity equal to zero. 4.The method of claim 2, wherein the parity based storage volume is aRAID4 or RAID5 storage volume.
 5. The method of claim 1, wherein therepetitive write command is part of a secure delete operation andwherein optimizing parity calculation and writing the pattern to theportion of the parity based storage volume comprise: writing the patternto the portion of the parity based storage volume without calculating orwriting parity.
 6. The method of claim 1, wherein the repetitive writecommand has an associated secure delete flag.
 7. The method of claim 6,wherein the parity based storage volume employs block-level stripingwith parity and wherein optimizing parity calculation and writing thepattern to the portion of the parity based storage volume comprise:responsive to the secure delete flag being set, writing the pattern tothe portion of the parity based storage volume without calculating orwriting parity; and responsive to the secure delete flag not being set,determining a parity based on the pattern and a number of columns in theparity based storage volume and writing the pattern with the parity tothe portion of the parity based storage volume.
 8. The method of claim7, wherein determining the parity comprises: responsive to the number ofcolumns in the parity based storage being even, setting the parity equalto the pattern; and responsive to the number of columns in the paritybased storage being odd, setting the parity equal to zero.
 9. The methodof claim 1, wherein optimizing parity calculation for the repetitivewrite command comprises optimizing parity based on user preferencesstored in a configuration file.
 10. The method of claim 1, wherein therepetitive write command is a. WRITE-SAME Small Computer SystemInterface (SCSI) command.
 11. A computer program product comprising acomputer readable storage medium having a computer readable programstored therein, wherein the computer readable program, when executed ona computing device, causes the computing device to: receive a repetitivewrite command and an associated pattern to be written to a portion of aparity based storage volume; optimize parity calculation for therepetitive write command; and write the pattern to the portion of theparity based storage volume based on the optimization.
 12. The computerprogram product of claim 11, wherein the parity based storage volumeemploys block-level striping with parity and wherein optimizing paritycalculation comprises: responsive to the number of columns in the paritybased storage being even, setting the parity equal to the pattern; andresponsive to the number of columns in the parity based storage beingodd, setting the parity equal to zero.
 13. The computer program productof claim 11, wherein the repetitive write command is part of a securedelete operation and wherein optimizing parity calculation and writingthe pattern to the portion of the parity based storage volume comprise:writing the pattern to the poi o of the parity based storage volumewithout calculating or writing parity.
 14. The computer program productof claim 11, wherein optimizing parity calculation for the repetitivewrite command comprises optimizing parity based on user preferencesstored in a configuration file.
 15. The computer program product ofclaim 11, wherein the computer readable program is stored in a computerreadable storage medium in a data processing system and wherein thecomputer readable program was downloaded over a network from a remotedata processing system.
 16. The computer program product of claim 11,wherein the computer readable program is stored in a computer readablestorage medium in a server data processing system and wherein thecomputer readable program is downloaded over a network to a remote dataprocessing system for use in a computer readable storage medium with theremote system.
 17. The computer program product of claim 11, wherein thecomputer readable program is provided in a storage controller within acloud environment.
 18. An apparatus, comprising: a processor; and amemory coupled to the processor, wherein the memory comprisesinstructions which, when executed by the processor, cause the processorto: receive a repetitive write command and an associated pattern to bewritten to a portion of a parity based storage volume; optimize paritycalculation for the repetitive write command; and write the pattern tothe portion of the parity based storage volume based on theoptimization.
 19. The apparatus of claim 18, wherein the parity basedstorage volume employs block-level striping with parity and whereinoptimizing parity calculation comprises: responsive to the number ofcolumns in the parity based storage being even, setting the parity equalto the pattern; and responsive to the number of columns in the paritybased storage being odd, setting the parity equal to zero.
 20. Theapparatus of claim 18, wherein the repetitive write command is part of asecure delete operation and wherein optimizing parity calculation andwriting the pattern to the portion of the parity based storage volumecomprise: writing the pattern to the portion of the parity based storagevolume without calculating or writing parity.
 21. The apparatus of claim18, wherein the apparatus is provided within a cloud computing nodewithin a cloud environment.